REMARKS 


The above amendment and these remarks are responsive to 
the Office action of 5 Mar 2007. 

Claims 1, 10-13, 17, and 19 are in the case, none as 
yet allowed. 

35 U.S.C. 112 

Claims 1, 10-13, 17, and 19 have been rejected under 35 
U.S.C. 112, first paragraph, as not complying with the 
enablement requirement. The Examiner apparently could not 
find sufficient support in the specification detailing how 
the generation of a goods receipt is used to approve and pay 
for an invoice. 

In response, applicant calls to the attention of the 
Examiner the following material from page 9, lines 2-22 of 
the specification: 

In accordance with the terms and conditions of the 
purchase order 87, vendor 48 returns an invoice 89 to 
SAP server 42 requesting payment for the goods or 
services. Responsive to receipt of invoice 89, SAP 42 
prepares and communicates transaction information 404 
to RCW 40, and RCW 4 0 provides that information in 
transaction notification 65 to requestor 46 in a 
format, such as a window or frame, including the 
transaction information 404 and a selection device, 
such as buttons 406 and 408, or the like, for accepting 
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or rejecting the invoice. 

In the event that requestor 46 accepts the 
invoice, or authorizes payment, an automated goods 
received (move ticket) is generated back to SAP system 
42 and payment made without further human intervention . 
[Emphasis added.] 

Applicant represents that the material above quoted 
provides to those of skill in the art a sufficient 
understanding of how the goods receipt (referred to above as 
a transaction notification 65 for an invoice 89 which has - 
been accepted 406 by requestor 46) is used to generate a 
move ticket back to SAP system 42 which will pay the 
invoice . 

Applicant's invention, however, is not directed to the 
payment of the invoice, but rather to the generation of the 
receipt. 

When a invoice is received from a vendor which includes 
an item marked as "receipt required", payment is blocked and 
notification sent to the user. The user responds by 
returning an approved receipt which is posted to remove the 
block and approve payment of invoice. 

Applicant requests that the rejection under 35 U.S.C. 
112 be reconsidered and withdrawn, that claims 1, 10-13, 17, 
and 19 be allowed. 
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35 U.S.C. 103 

The Examiner interprets "generating a goods receipt for 
approving an invoice" to mean "comparing an invoice to a 
receipt." That such "generating" includes "comparing" is 
correct . 

Claims 1, 10, and 12 have been rejected under 35 U.S.C. 
103(a) over Maners, U.S. Patent 6,507,826 in view of 
University of New Hampshire Financial and Adminsitrative 
Procedures , hereinafter, Procedures . 

Claims 13, 17, and 19 have been . re j ected under 35 
U.S.C. 103(a) over Maners in view of Procedures and further 
in view of Furphy et al. U.S. Patent 6, 882, 98-3. 

Claim 11 has been rejected under 35 U.S.C. 103(a) over 
Maners in view of Procedures, and further in view of Barnes 
et al., U.S. Patent 5,970,475. 

In rejecting these claims, the Examiner asserts several 
concepts as being obvious, drawing on his own many years as 
an accountant and, of course, the cited art. 

With respect to claim 1, at page 6 of the Office 
Action, the Examiner seems to be equating invoices above and 
below a certain amount to those which relate to receivable 
and non-receivable commodities (in determining whether to 
execute a negative or positive confirmation process) . This 
is not the meaning set forth in applicant's specification at 
page 13. Applicant has amended claim 1 to more clearly 
define commodities . 
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Applicants invention is represented as being 
particularly useful for goods and services not coming 
through a receiving dock, including automating preparation 
of a move ticket responsive to requestor entered positive 
confirmation [Specification, page 4, lines 15-19] . 

Commodities that typically designated as needing 
positive confirmation are those that would not flow through 
a traditional receiving dock where a dock worker takes parts 
off a truck, counts them, and then creates a receipt 
transaction into an application which bridges to the 
accounts payable system where a three way match would occur. 

In applicant's invention, the commodities where 
positive confirmation would be configured are those like 
services. Examples of such services includes a painter 
painting an office, an electrician wiring a room, and a 
telecommunications worker installing a network router. The 
business that receives benefit from such services and pays 
for them does not want the invoices from the vendor for 
these services paid until a person explicitly concludes that 
the service was done and done to specification. 

In applicant's invention, the way the positive 
confirmation process occurs this is: an invoice arrives and 
is checked against the purchase order. It is determined 
that the purchase order item referenced on the received 
invoice has a positive confirmation designated commodity 
(that is, a receivable commodity) for which there is no 
existing receipt, such as may be expected from a dock worker 
for commodities which do flow through a receiving dock. In 
accordance with applicant's invention, the system uses the 
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invoice information to send a positive confirmation notice 
to the requester. That requester must respond to the 
positive confirmation notice. The response can be either: 
do not pay or pay it. If the response is to pay it, a good 
or service receipt is generated. Once that receipt reaches 
accounts payable (as an automated receipt transaction file) , 
the three way match occurs and the invoice will be accepted 
for payment. Applicants are not claiming to be the. first to 
do three way match. Rather, the novelty resides in the way 
the receipt for the goods or services is generated from the 
invoice and purchase order and submitted by the requester. 

Further with respect to- claim 1, at page 6 of the 
Office Action, the Examiner asserts that Procedures teaches 
three-way match, and it would be obvious to ■ combine 
Procedures with Maners. 

The process taught by Maners is as follows. An invoice 
arrives for which there is no receipt.- Consequently, the 
invoice is not accepted for payment. A purchasing person 
would then must investigate the missing receipt. To do so, 
he would need to contact the requester to see if the 
goods/service was received/performed. If the answer is yes, 
the purchasing person would then contact a person that had 
access and authorization to create receipts. That person 
would then create the missing receipt which would flow to 
accounts payable where the three way match would take place. 
Applicants claimed process for generating the receipt, as 
described above, improves on this procedure. Consequently, 
the combination of Maners and the three-way match taught by 
Procedures do not teach applicant's process for generating 
receipts. 
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With respect to claim 10, at page 7 of the Office 
Action, the Examiner indicates that front-end and back-end 
processing are not claimed in sufficient detail to clearly 
demark them. 

Applicant has amended claim 10 to more clearly demark 
the front-end and back-end systems. 

With respect to claim 11, at pages 9-10 of the Office 
Action the Examiner asserts the obviousness of combining 
Maners and Barnes regarding posting (page 6) . 

Applicant notes that the claimed invention is not 
directed to the fact that posting a receipt causes an 
invoice to be paid. Rather, applicant's invention is 
directed to the manner in which to collect the receipt from 
the requester responsive to the arrival of an invoice from 
the supplier. Applicant is not merely claiming that doing a 
receipt triggers payment. Rather, it is the process of 
generating that receipt. The combination of Barnes, Maners 
and Procedures does not teach this process. 

With respect to claim 12, applicant has amended the 
claim to depend from claim 10, which now distinguishes 
Maners and Procedures as previously described with respect 
to claims 1 and 10. . 

With respect to claim 13, 17 and 19, the Examiner 
refers to claims 1 and 10. Applicant has previously 
discussed the distinctions with respect to Maners and 
Procedures . 
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With respect to Furphy, in applicant's invention, when 
an invoice is received and it is determined that the invoice 
includes a mismatch, that is a commodity marked as 
receivable for which a receipt has not been previously 
generated, an E-mail request is sent to the original 
requestor (not the buyer) to generate the receipt. 
("Separation of duties" requires that applicant not request 
such of the buyer.) Applicants resolve the mismatch by 
requiring that the original requestor provide a positive 
confirmation response. 

Thus, applicant's invention relates to the generation 
of the receipt of goods. Goods designated as receivable and 
which are received through the receiving dock will have that 
receipt generated by receiving dock personnel, whereas goods 
designated as receivable and which are not received through 
the receiving dock will have that receipt generated by the 
original requestor, which latter receipt is requested by an 
e-mail request directly to that requestor. 

Furphy, on the other hand, is silent on the process 
implemented for generating the receipt. Furphy provides a 
single interactive platform 15 for processing transaction 
data for both buying companies and selling companies (Col. 
5, at line 12) . At col. 7, line 60ff, Furphy teaches that 
receiving documents provide receipt data corresponding to 
the products actually received by the buying company, which 
will then be combined with information from the purchase 
order to determine the total cost of goods received. At 
col. 8, line 38ff Furphy describes the resolution of non- 
matching charge codes, and requesting resolution from buyers 
or default buyers. At col. 9, line 34 ff Furphy describes 
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that further processing is executed when receipt data and 
invoices do not match, and at col. 11, line 56ff the use of 
rules-based schemes to resolve differences, and at col, 12, 
line Iff the use of a workflow process for resolving charge 
code discrepancies. Similarly, at col. 15, line 57 ff 
Furphy refers to resolving discrepancies between purchase 
order data, invoice data, and receipt data. 

However, in none of these teachings, nor elsewhere in 
the reference, does Furphy teach applicant's claimed process 
(as described in the second preceding paragraph) for 
generating goods receipts, as distinguished from the 
subsequent use of such receipts in the purchase order, 
invoice, goods receipt three-way match. 

Applicant has amended the claims to more clearly define 
the process for generating the receipt document, and 
requests that they be allowed. 

SUMMARY AND CONCLUSION 

Applicants urge that the above amendment be entered and 
the case passed to issue with claims 1, 10-13, 17, and 19. 

The Application is believed to be in condition for 
allowance and such action by the Examiner is urged. Should 
differences remain, however, which do not place one/more of 
the remaining claims in condition for allowance, the 
Examiner is requested to phone the undersigned at the number 
provided below for the. purpose of providing constructive 
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assistance and suggestions in order that allowable claims 
can be presented, thereby placing the Application in 
condition for allowance without further proceedings being 
necessary. 


Date: 3 May 2007 

Shelley M Beckstrand, P.C. 
Patent Attorney 
61 Glenmont Road 
Woodlawn, VA 24381-1341 
Phone: (276) 238-1972 
Fax: (276) 238-1545 


Sincerely, 


C. S. Baumann, et al. 


By 
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